Shareware Overload Trio 2/Shareware Overload Trio Volume 2 (Chestnut CD-ROM).ISO/dir24/aprs60.zip/MARATHON.TXT

Text File | 1994-09-28 | 6KB | 88 lines

MARATHON.txt 6.0          APRS at the Marine Corps Marathon 1993 (and 4)


Whew! Its over!  14,000 runners Plus family and spectators at the Marine Corps
Marathon!  Here are the immediate lessons learned today:  1) MC chase vehicles
(HumVees) were not identified nor available until 45 minutes before start, to
install 3 GPS-packet tracking devices!  A) Mag mounts dont stick to ragtops
or Aluminum, B) HumVees run on 28 Volts, C) battery jumper between two 12 volt
batteries is sealed on both batteries in tuna fish size can of grease under
passenger seat, C) clearance between Battery posts and seat is less than 1/4
inch!  Last one was finished 1.5 minutes before the starting Howitzer fired!
(30 feet away!)  Then I was stuck there while 14,000 mobbed past me!

    Finally got back to Comm tent to see that all three vehicles were tracking
and showing up beautifully on the PC screen running APRS software.  The rest
of the event went beautifully, with all three vehicles (Lead handicapped, Lead
runner, and Tail-end-Charlie) transmitting their GPS position once a minute.

Here are the lessons learned for the APRS software (corrected in V2.13):

   1) The automatic Dead Reckoning was a pain.  With the entire event fitting
on a two mile screen, a 1 minute error in the PC clock resulted in a 1000 yard
error in dead reckoning.  FIX:  DR is now an ON/OFF toggle.  Also the alt-
SETUP-GPS-TIMEsync command will sync each PC to any GPS packet on-the-air.

   2) Downed runners and medical reports soon filled the screen.  There was no
mechanism for removing old positions and objects!  FIX:  APRS now keeps a
timer on EVERY packet instead of one timing scheme per station for ALL
objects from that station.  Also now there is the KILL command so the
originator of an object can KILL it from ALL screens in the net.

   3) APRS performs better than normal packet for realtime tracking, object
and position reporting and operator conversing, but connected links are better
in classical packet applications, such as passing patient lists to hospitals.
We had a separate medical packet link which performed that function admirably.
A single APRS net could not possibly "do everything" at an event of 14,000
runners (at 1200 baud anyway).  Separate APRS nets on separate frequencies for
separate functions could be built into an impressive "TACTICAL" network system.
(P.S. The voice ops were outstanding and professional!  HAM radio (voice) was
THE primary dispatch authority for all ambulances)

   4) In the MAIN COMM tent with 4 two meter nets (plus other bands) there was
very little QRM.  All APRS packet stations at all checkpoints were mandated
to operate with only 1 watt.  A central digipeater on a building more than a
Mile away from all other stations ran 15 watts and all packets went via this
WIDE area digipeater.  The only packet QRM heard on the voice nets in the main
COMM tent was so rare that no one expressed concerned. (Whew!)

   5) The APRS message mode was slow for operator notes, comments and queries,
But ACK times were often minutes or more.  FIX: Each message line is now TIMED
individually (instead of as a whole group) so that older messages are not
retransmitted with every new message line.

   6) The event operated on on the local 145.79 APRS frequency which also
included two dozen other APRS stations, the 9 Marathon stations and ALSO the
Point-to-point packet link!  The conventional packet link soon moved to another
frequency for their own sake, and our packets got through better.  FIX:  In
version 6.0, APRS now has an alt-IGNORE command so that all special event
stations ignore all APRS and other packets EXCEPT those addressed to SPCL.
This keeps stations from VA to NYcity from cluttering the P and L-Lists of
the stations working the event.

   7) With APRS we could easily track the lead, pack and tail runners, which
was great for PR, but after the Lead and PACK crossed the finish line, only
then did all of the 80 ambulances begin to move to pick up downed and dead
runners.  We did not have enough GPS devices.  FIX: In subsequent events we
have noticed that it is a WASTE to put GPS on the LEAD, PACK and TAIL vehicles
since the position, course and speed of these vehicles is TOTALLY PREDICTABLE!
With the DEAD-RECKONING of APRS, these vehicles can be placed on the APRS net
as objects and only occassionally updated based on voice reports.  APRS still
moves them by dead-reckoning and all other APRS stations cant tell the
difference!  This year, we hope to have 8 or more GPS devices on the critical
life support ambulances.  (DO consider a GPS for the TAIL vehicle, because it
is far less predictible than the others)

   8) The complete event can be re-played from MARATHON.hst to see how it
went.  To make sense out of it all, play back only one mobile at a time, and
turn Callsigns off.  WB4APR-9 was the lead Handicapped vehicle (started 15
minutes or so before all runners), W3ADO-9 was the lead runner, and MOBILE-9
was Tail-end-Charlie.  Statistically, we did very well.  W3ADO-9 was turned on
at 0827 but did not move until 0902.  It was removed from the vehicle at about
1127.  Transmitting at once a minute, there should have been 145 posits trans-
mitted.  We counted about 115 in the file.  The missing packets could have been
either colisions, or bad GPS fixes (masked by buildings) so that the same posit
was transmitted more than once (and therefore filtered out as a dupe by APRS).
The result computes to almost an 80% success rate!